@joelparkerhenderson Testing in all encodings is turning out to be more of a pain than I expected. What are your thoughts on this? Should unaccent only work on UTF-8 (or UTF-16, I'd imagine) strings, or should it operate on as many encodings as possible?

@joelparkerhenderson I've pulled in your latest changes and updated the benchmark.

Is it possible to get this PR merged ASAP, addressable gem using this as a dependency and this takes lot of memory. I found this pr when when I was about to raise one with some optimizations which are already done in this PR
Thanks in advance

Ref redtachyons@2da4a4b

Thanks! I'll go through these today & tomorrow. First glance it all looks fine.

@pnomolos You're asking great questions. I propose that a reliable way for now is to do just UTF8, and also append that to the gem name i.e. name the gem sixarm_ruby_unaccent_utf8_libunac. I've talked with a couple people who prefer the greater specificity. I'll let you make the call; what would you like?

BTW it is better to gitignore coverage files

@redtachyons Thanks, I'll ignore /coverage/ and /coverage.data, in an independent commit. I'll also change from listing the dependencies in Gemfile to using the "gemspec" line as above, in an independent commit. And also ignore the Gemfile.lock file.

@joelparkerhenderson We're still using this gem internally - if I rework this commit would you consider pulling it in and cutting a new version of the gem?

Yes. What version of Ruby are you using? What I suggest, if you want, is I can get the gem up to date with Ruby 3. I have time this weekend. Then could you add your improvements on top of that? (Or do you prefer a different way?)

Hi Joel,

If you have time to do that it would be great, as we're hoping to move to Ruby 3 sometime later this year.

Thanks!

Hi @joelparkerhenderson if you don't have bandwidth to get to this I'd be fine doing two PRs - one for Ruby 3 support and an updated one for this. Would that be OK with you?

Thanks,

Phil